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{5Ti a context-dependent, multiply binding name 
esolution system. A name resolver is provided con- 

tern or both. Requests to a given serv.ee or domain 
name are reserved to the appropriate IP address. The 
"mended recipient of the request is resolved based upon 

eluding: information about the sender (e.g. geographical 



location, specific requester identity, etc.); 

about the intended recipient (e.g. toad ba^nceat *e 

receiver, type of service, etc.); mtormauon oortamd 

within the request itself (e.g. type ol 

or other information (time of day, date. rarKloniaelection 
of recipient, e.g.). The system is implemented in hard- 
ware and/or software, and the resolution criteria can be 
made interdependent or independent. 
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Description 



This invention relates to systems for context-de- 

when a host wants to communicate with another host or 
^tea^rvtoe « another nostc* the network, the ad- 
dress is typically resotved in an absolute manner; that 
STI* naming service ol the network resolves a given 
name to a single iP (Internet Protocol) ^ress^For ,n- 
sSce, a dorna* name serves (DNS) call resoWes a 
name to a single IP address or host name on the Inter- 

nQt ' when there are many connections to a given host 
orser^mer^umng^gesUondegradesthe^era 
oerformance. The service provider may upgrade the 
seSTeTto increase its capacity. In this case. n or- 
the rnodHlatton ol the serv.ce transparent 
to request hosts, a demultiplexer may be used, as 
Sed by way ot example in Figures 1-2. For ,n- 
stence Tn Figure 1 a call to Service 3 will be unquely 
reXd to tfiat service's IP address and transmitted 
nlre ^dingly, because there is only a single b.nd.ng 
n™S nal resofcer to the « - ^1 
general, in a conventional system such as that .llustrat 
Z in Figures 1 , 2 and 2A, there will be a s.ngle b*d.ng 
between a name and an IP address. 

Yet another alternative is lor a special type ol de- 
multiplexer, which may monitor the traffic and from the 
"Lent ip addresses can ^'ect stat^ics^as re- * 
sconse time and/or the toad on the corresponding IP 
hoT and use this information for toad balancing by 
b^gTrequested name to an IP address for a host 
which is less heavily loaded. 

« Service 3 is upgraded to include Services 3.1 * 
through 3.Y, then the demultiplexer is added (see Figure 
2) ™ ^requesting or DNS resolving host reserves the 
request as usual and sends it out over the (Inter-or In- 
ra-)network. but the demultiplexer is mterposed be- 
tween t^ network and the service(s), to route the in- ■ 
coming requests to one of the services. Note that in this 
cas^L^festillas^glebinding between the DNSand 

the demultiplexer. HAmutti- 
A problem with this approach ls that the demutt 
plexer acts as a limiting factor on throughput, and add.- 

services that itserves. Amechamsrms needed whereby 
Z JTcrWc- point and bottleneck can be avoided, 
while still providing access to the services tor remote 

An alternative approach to decreasing congestion 
IS through DNS spoofing, where the name ^resolve -» 
looled into giving out a different name binding, by keep 
"name resolver updated ^-^suchTs 
,oad distribution on target servers. An example of DNS 
spoofing is shown in Figure 2A. in wheh a requester 2 
issues a request using the name 'sun.com , and a DNS 



tookup A looks it up. The host (1 . 2 or 3) to whehthe 
is bound will depend upon criteria employed at 
rd?stinati W ^.asdeterminedbyDNSsr^n9 

sTr^ce 6. Such criteria may include toad on the hosts 
M avM etc. The DNS spoofing 
the hosts 1 -3 periodically or at demand, and binds one 
oTthem at a time to the DNS lookup name resolver tor 

p thebindingarenotrelat^^ 

er they rely only upon information at the dest.nat.on. 
Thus much information that could be important in mak- 
ing a binding is not utilized, in none ot the known sys- 
tems is caller context used. 
IS it would accordingly be advantageous to have a 
system which takes into account the context of the re- 
quester in the process of name resolut.cn. 

Various respective aspects and features ot the «n- 
vention are defined in the appended claims. 
20 A context-dependent name resolution system is 
presented, which implements predetermmed crrtenafor 
static or dynamic binding of a -name" to any one ot sav- 

ed for the binding is determined by a 'name resolver 
25 ^sing context information that is explicit* ^ 
me Requestor in a name resolution fefepctf othe 
■name resolver". The "name resolver^** « ,mple 
mentedasaserverprogram. ^« 
prising bindings of a -name' to several <War««™tonc 

fines the criteria for selecting an "?^££*£> 
For instance, the name may be an internet UHL of the 
ftSn -www.sun.com-. and the resolved to object may be 
^P address ot the type 192.146.95.82. Thusthe 
35 -name resolver- will store the tuple: <www.sun.com> 
<"p addrets 1» <lP_addressJ>>.... and will store ip* 
iciest w*ich> address to b^ 
a lookup request specifying -www.sun.com is recerved 

bV ^By enabling multiple binding support in the 'name 
resolver- several advantages are realized. First, the 
system enables new resources to be addec I transpar- 
ently to the caller. When a new server « ^ 
tribute the toad lor one or more hosts corresponding to 
the name -sun.com". tor instance, the IP address for the 
new server is simply added to the tuple in the name . re- 
solver. along with any desired policy cntena. e.g. to use 
only between 9 a.m. and 5 p.m. 

Secondly the fundamental limit to scalmg which is 
inherent in todays single binding systems ^mo^ 
by enabling multiple destination servers providing the 
sameservicetobereferencedbythesame name han- 
dle by the caller (for example 'sun.com"). and the name 
to beresolved by the name resolver to different phys.cal 
5 computers servers, depending upon caller context. 
E£ instances of the name resolver may be runn«g 
on different physical computers, and many instances .of 
Z services may be running, and the requester will ac- 
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cess the name resolver closest to him; and the rescued 
object that is closest to the requester or that can best 
serve the request (based upon some selected or prede- 
termined criteria) will be bound to the request, all trans- 
parently to the requester Another advantage ol the sys- 
tem ot the invention is that it allows resources to be eas- 
ily replicated transparently to the user, eliminating any 
single point of failure in the network or at the service end 
point It one valid destination fails, is not responding or 
is overloaded, the name resolver is already capable of 
binding a "name" to multiple destinations, and the una- 
vailable destination can be disabled in the name resolv- 
ed internal tables, using administrative means. 

The context that may be used as a basis for the 
binding is variable; it may include information about the 
requester (e.g. requester IP address, domain name or 
inferred geographical region), about the destination 
(with similar alternatives), about the request itself (e.g. 
tvpe or quality of service requested), or about independ- 
ent information (e.g. time o( day or time zone ot the point 
ol origin of the request). 

The system may be implemented (eg as part ot a 
computer apparatus) using hardware, software, or com- 
binations thereof. 

The invention will now be described by way of ex- 
ample with relerence to the accompanying drawings, 
throughout which like parts are referred to by like refer- 
encee, and in which: 

Figures 1 -2A are diagrams of present network sys- 
tems used for destination addresses tor requests. 

Figure 3 is a flowchart illustrating a method accord- 
ing to an embodiment of the present invention. 

Figures 4 and 5 are diagrams of network systems 
incorporating features ot embodiments ot the present in- 
vention. , 

Figure 6 in an illustration of the operation of an em- 
bodiment of the invention using geography-based res- 
olution criteria. 

Figure 7 is a diagram depicting zones in which do- 
main name service resotvers and service location re- 
solvers of the invention may be located. 

A method according to the invention is illustrated in 
Figure 3, and Figures 4-5 shows a suitable systems im- 
plantable on the internet or Worldwide Web, the In- 
temet or an Intranet., incorporatingfeatures ot the name 
resolution system. 

Name resolution can include any kind of name res- 
olution lookup tor binding one object to another. This in- 
cludes binding the name ol a service to a host computer 
(or its IP address) that provides that service, and binding 
the type ot service to the name of a service providing 
that type of service. It also includes resolving a name in 
one domain to another name in the same domain, and 
to another name in a different domain. For the purposes 
of this invention, the terms 'service" and 'host' can be 
considered synonymous, as can "service location and 

'host location'. 

The system includes three fundamental features 



that can be implemented singly or in any combination 
with one another multiple binding of destination ad- 
dresses to names; caller context name resolution in con- 
nection with such multiple binding; and name resolution 
policy considerations, i.e. independent criteria upon 
which such resolution is based. 



unn* Resolution : An Example 

10 An exampleof name resolution occurs, torinslance, 
when a user wishes to view video, e.g.a movie, on his 
or her computer. An application running on the computer 
is used to make a procedure call to the name resolver 
to determine which server can serve a movie, e.g. 
is service.handle = name_ser\ricejookup('movie ) 
where the string -movie" is passed to a server, which 
then returns the name of the service providing that mov- 
ie (or it may return a linked list of services providing mov- 
ie services, from which the user may be prompted to 
20 select one). 

The server may. by way of example, return a single 
service name (e.g. "quicktime') in the variable called 
"service_handle'. Next, the application must determine 
which server host can provide this service to this client; 
25 to do this, it makes another name resolution call: 

host_handle = rvamejiostnarnejookup 

(service Jiandle) 

and passes it the variable "servcejiandle returned by 
the previous call. This call returns it the name of a server 
30 which is listed as offering this service. 

The network location ot this server must now be de- 
termined, so that the user's computer or workstation can 
connect to it to get the movie service, and so it makes 

as ^ e ^hostJP.address = nomejiostaddressjookup 
(host Jiandle) . 
and finally obtains an IP address of an appropriate host 
that can provide the movie service to the user. 

Further calls to this quicktime server may determine 
40 a list of movies that are available. Alternatively, adesign 
may be had in which the caller simpty specifies the name 
of the movie he wants to see, and the name lookup re- 
turns to the caller the IP address of a host that e cur- 
rently able to serve the requested movie to the caller 
45 All of or some of the above steps may be combined 
in more integrated calls to the name resolver 

In the present invention, in addition to the above, 
an additional parameter is passed to the 
name.hostaddressJcokupO function above (or to all 
so the functions above); this parameter may be called the 
caller.contsxt. This caller^context is used by the name 
resolver to help it decide which IP address to use. Thus, 
the calls would look like: 

hostJP.address = name_hostaddress_tookup 
55 (host.handle, caller_context). Caller_context is a cook- 
ie (or structure) that may include information such as the 
caller's IP address, its point of origin, the quality of the 
requested service, or any other context that might be 
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relevant These contexts must be well specrf.ed and 
CT£nU) standardized, so that many drtterent 
He «3« 6 can interoperate properly. The parlieu- 

^"^m^iment uses jester — 
depended intelligence to determine which c several 
destination hosts should be utilized, or in other words, 

a 1 "name- request. The contexHiependent .ntelh- 
l!Z -mpWd as hardware or f^™ e 
binatton ol both, allows the 'name' resolute to be 
SXpon some context information from the reques- 
r^uponthe'name- being resolved inaconte^ 

Uee Zr»T™ optional* dependent upon cntena 
such; as load balancing on the destination. 

As shown in Figure 4. a requesters 100-120^ 
which there may be an arbitrary number, each compnse 
Outers or workstations on a local network, served 

2£l workstations, personal computers, or any n£ 
wTrkable computing device, with local processors (1 30, 
rrmemory^l40, etc.), mass storage (not shown) and 
n«woTk connections. The server 150 also includes a 
SSS Processor 160. ™ 
age and necessary connections and control hardware 

or may be a separate unit. It may be implemented en- 
^ software. L* as program modules stored .n 
Zl storage and/or the memory 170. or it may be a 
stTd-alone device, with its own logic or processor and 

^ STEl. ejected to a broader network 

network) or the WorldWide Web, via a network <^ nec ; 
tio^Te Q a Viine) 260. On this network 170 is cpt»nally 
a ^na m i"esor,er200, which n^y be implemented 

eTrSme refers 1 80 and 200 may both be used or 
either may be used by tart. (See discuss** ol F.gure 
7 below ) 

Destinationh«ts2l0-230rnayal 6 obeconvent,on- 
al computers or workstations with processors (such as 

nmwoTk connecuons, etc.. as needed to implement con- 

the present invention. 

Referring to the flow chart of Figure 3, when a re- 
quester (such as 100-120) sends a name 

la ol conventional systems, the name resoiver 80 n 
iudes multiple binding tables and/or functions mp e- 
mented by appropriate logic or program modules) to re- 

tination host (such as 210-230 in Figure 4). 

An example ol such a multiple bindmg wouldb the 
binding of multiple, geographically dtsparate desttna- 



Germany wishes to access www.sun.com (the VVW 
servertcisunMicrosystems,.nc.).hec,s 
use the Uniform Resource Locator (URL) 
5 sun com') Thus, the user sends the request from re- 

Seterm^es that the requester is 
20 in Figure 3). The selected destination may either be 
h £ United States or elsewhere in Europe, since Sun 
to Microsystems in this example has two sun.com toca- 
ttmTSto there is a valid European local dest^tcn 
330, the name resolver320 resoles the dest^ton ad- 
dress to sun.com (Europe), as indicated at box 30 of 
? igure 3. This rested destinaton is then seated or 
ts the request packet(s) (box 40 of Figure 3* and the 
questis forwarded to sun.com (Europe) (box 50 of F.g- 

Following are lists ot context^ependent resolution 
criteria applicable to the invention and usable at box 30 
20 of Figure a. where resolution may be based upon re- 
quester information, destination information, request 
contents, or other information : 



A Resolution Based U£on Ro< 



Examples ot manners in which the resolution de- 
pendent upon requester information may be earned out 
include: 

30 1. resolution based upon the domain name of the 

riesolution based upon the intened (looked-up) 
actual geographic region ot the sender; 
3. resolution based upon other geography-related 
35 information ot the sender: 

4. either directly ascertainable f rom the request 
(city/country into, e.g.); and/or 

5. indirectly ascertainable (area code, address, 
40 etc.); 

6. resolution based upon quality ot service desired 
by the requester; and 

7 resolution based upon requester's time ot day or 
45 time zone. 

Examples ot manners in which the resolution de- 
so pendent upon a specified or intended destination or re- 
ceiver information may be carried out include: 

1 resolution based upon the load at the receiver, 

2 resolution based upon the inferred (looked-up) 
55 actual geographic region of the server, 

3. resolution based upon other geography -related 
information of the receiver. 
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4 either directly ascertainable from the request 
(city/country into, e.g.); and/or 
5. indirectly ascertainable (area code, address, 

etc.). 

Criterion B. 1 can be resolved either based upon in- 
formation as percervedatthe sender - d ^ S fT^ 
information as it exists at the receiver end and rested 
T*m sender end. For example, the sender mgM Se- 
quent* send requests toaparticular server. 
graphical region or organization. In thscase. .tmay be 
^dvTtageous to regularly poll one or more often-^sed 
destLtkU to determine their level(s) of actwrty. Alter- 
naSTuch polling could automatical* be earned out 
: 0 any donations 9 .or tf*h the sender de = 
hat its number ot requests exceeds a certain threshed 
or tor a top predetermined percentage of r8quj^«rt 
byihe fester (e.g. all destinations tor whK* the 
number oTrequests exceeds N1%, or the top N2 
nations to which the sender makes rec . uests ^ r6 p ^ 
and N2 are appropriate predetermined numbers). Poll 
fng canbe implemented as program modules integral* 
SL. resolver (s), either entirety in one or m more 
™e tocation (e.g. partial* in a local name resolver 
and partially in the destination server). 

Memative* or in addition, criterion may be 
based upon information at the receive end at the t me 
oufndinTthe request, and resolved at the recerver. 

a Resolution Based Lfeon Request Contents 

1 type ot service requested; 
2. specific inlormation (or type ot informat.on) re- 

^anyother implicit information interred from the re- 
auest; and/or 

4, any other explicit inlormation obtained Irom the 
request. 

a Resolution n» n »ndent Upon Other Factors 

1. randomly generated selection of destination 
based upon qualified list; and/or 

2. other independently developed inlormation. 



These resolution criteria can be used smgty or in 
any desired combination with one another, as specified 
Tthe requester or the administrator ot the destination 
q wwer owner or service provider). For mstance. .n 
he'example ol Figure6the resolution of thc~on 
address to sun.com (Europe) could be modit,edj the 
£2 o. sun.com (Europe) is larger by ^^deter- 
mined threshold amount than the load at sun.com (USA) 
TTn ^th case the sun.com (USA) resolution could 
override the default sun.com (Europe) resolution for, re- 
questers in Europe, either at all timesor on* dunng 
peak European hours, which correspond to off-peak 
hours in the United States. 



An extension of this system is in the ^<** 
services provided at the receiver network ol a request. 
^ stance, a grven organization may have many da- 
tabase servers, and request tor access to ^en ^ 
5 maton may in conventional systems be routed to the 

^nation resolutfcx, WHh multiple address resoMcn 
binding, multiple database servers (or other desMtan 
^ts) such as 210. 270. 2B0. etc. (see Figure 5) may 

a local service resolution server, such as server 300 tn 
F^re 5. is provided. The server 300 includes tables, 
program modules or the like as o^lred toresoh^ are, 
quest to any one ot several to many IP addresses. ^ 
,5 Lection of a given server to ^^^^ 
pend upon, lor example, load at each ot the serve s. 

in general, the resolute systems or ^baysterns 
will be £i one ot three 'zones' (see Figure 7): the send- 
: ^oneT(upto. e.g.. the servers firewall or Intent 
*o server); the name resohver system's zone 2 (wtmh may 

1 which is not in the receiver's system; and the receiver's 
zone 3 Service location name resotvers may be in any 
of zones 1-3; typically, destination lookup name resotv- 
25 ers.wh^maycomprisemultiple^indingc^n™ 
services (DNS's). will be in either zone 1 orzone 2AX 
be understood that zones, tor ^ ^ 
application, are administrative boundanes, and need 
not correlate to actual network boundanes. 
30 ™L present embodiment can interact wtthexistmg 
systems in a number of ways. For stance, ^ secure 
systems where the source address 
,equest by a firewall (and only, e.g., the domain name 
remains) then the entire source address would not be 
3s ue™ to resolve the destination; the name resorveMS 
provided with the program instructions or crcurtry to £ 
nlement this. Note also that the DNS name resolution 
C be a distinct operation from service locate, and 
thus the destination can be selected due to a combina- 
40 tion of considerations including source address, re- 
vested destinaUon address, and requester** in- 
cluding the type ot request made or service equestecL 
The mulUple binding feature of the invent™ allows 
asingle name "internet address (e.g. URL addresssuch 

actual servers (or services) as desired. This has adis 
S advantage d allowing modifications, upgrades or 
repfcationstob^madetothea^tinat-onserv^ 
out modification of the destination address or serv.ee 

so ^^^^^-^^^^^ 

includeaddmgserversorservces.orestabl.shmgam.r 

ror 1 at a location geographical* near a large source 

d Te^may'be security and consistency implications 
55 of multiple bindings, with concomitant solutions. It a des- 
Ltion address can be multip* bound, a name resole 

deliberate* or otherwise. While this may also be a prob- 
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lem with existing single binding, multiple binding may 
estate "cttJrt* of the problem. Thus, the system 
ofTeTve*trin may be combined wrth P^~< 
tables tor verification that a given binding « _ vattd Very 
^ure systems may wish to limit their mulnple binding 
oa ^ 

°es or even maintain the current system of stngte bind 
ino as to as internet or Web transmission is concerned, 
ement multiple binding only behind a f.rewall. 

furXy bo used to ensure vaWc1b t nd t ngs, and o. 

modifications or additions to the bindings. 

S^s maybe had by designaUng a given name 
JES as a default resolution, and utilizing a ema- 
^ resolutions only upon the request meet.ng prede- 
^cnieriatsuch as load imbalance, g^graphca. 
Hi^mce specific sources ol the request, etc.). 

^h^equest may resolve) may be added without the 
r^esteXng aware ot it. and indeed substitute 

quester. 

n i„ i,-n frf~*~ Uoon Ca » er 



coined with those of the independent claims »er 
pCateandincc^binaticmc^ermanth^ 

set out in the claims. 



Claims 

1 Asystemfornan^resolutionofatleastonerequest 
" directed to a destination name ot a rece.ver and is- 
sued from a requester system, ™> udin 9 : 

a name resolver connected to the requester 
service and including 

predetermined information «^ reteVin 9^ a fl 1 ' 
: Sy of destination addresses with sari destma- 

tion name; . . n 

a criteria selection subsystem configured to 
provide a selection ot at least one said Ra- 
tion address based upon at least one predeter- 
■o mined criterion; and 

a destination address binder configured to b,nd 
said destination name with said selected desti- 
nation address. 



The system ot the invention may be 
cenerallytotheuse ol caller context tot name resc4u«ori 
£*S Z« the requesting user (e. fl . in vanabto 
^caller context") can be passed to appropnate 

,Un *Te 9 r^dle , »«*J— ■ 
^W^e - name^tnameJooKup 

(service handle. caller_context) _ 
Here me function service.handle executes a service 
11 lockup based upon the input "movie', as well as 

alona with (again) caller_context. the function 
hoTt handle then returns an appropriate host name. 

whe™ user desires an encryption service, and several 

tS r^ed h callage*), or ^re may be 
i"iv?override in the caller_context by wh.ch the 
user can select a higher level of security. 

"general, as noted above, the Invention ma be 
imp emented at the sendees system or at the 
tion system, or indeed at points in between (e.g .at proxy 
sewers Note that single points ot failure 

M bmrJng name resolutcn system ,s 
^^Patolarand preferred aspects of the invention are 
set ou in "ht accompany^ W^^^ 
ent claims. Features of the dependent cla.ms may be 



25 2. "me system of claim 1 , wherem sari at least^ one 
upon information explicitly contained within sari re- 
quest. 



to 3 The system of claim 2. wherein said information in- 
cludes an address ot said requester. 

4, me system of claim 2, wherein said ^ orr ^^ 
bated upon at least a portion ol contents of sari 

35 request. 

5 The system of claim 4, wherein sari portion of said 
contents includes at least one of : 

40 a type of service requested by said request; and 

a quality of service requested by said request. 

6. The system of claim 1. wherein said at least ^one 
pTedeTermined criterion includes a cntenon based 
45 upon information not explicitly contamed wnthm sari 
request. 

7 The system of claim 6. wherein sari information 
pertains to a geographical region of sari requester. 
M 8 The system of claim 6. wherein sari information 
pertains to a geographical region of sari rece^er. 

9 The system ot claim 6, wherein sari information in- 
55 ' dudes toad information relating to said rece-ver. 

10 The system of claim 6. wherein sari intor matton » in- 
dudes at least one cf time and date mtormation. 
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11 . The system of claim 1 , wherein said binding is to a 
port at said destination address. 

12 The system of claim 1, wherein said binding is 
based at least in part upon a random selection ot 
one said destination address. 

13 A method tor context-dependent binding of a desti- 
' nation name to a destination address in a name re- 

lerhavingapredeterm^^ w 
aW) predetermined correlations ot destination 
names with destination addresses, wherein at least 
one said correlation is a multiple correlatton corre- 
cting a plurality of said destination addresses with 
a single destination name, including the steps ot: « 

? (1 ) receiving said request at said name resolv- 
; er; and 

- <2> based upon said multiple correlation, re- 
,; trievtng at least one said destination address 
Irom said plurality of destination addresses. 

1 4. The method of claim 1 3. further including after step 

2 ' ^^^binding said retrieved destination address • 
to said destination name. 

16. The method of claim 14. further including after step 
3. the step of: , l , . . 

(4) transmitting said request with satd desti- 
nation address. 

16. The method of claim 13, wherein said multiple cor- 
rection is based upon information explicitly con- ^ 
tained within said request. 

17 The system of claim 13. wherein said multiple cor- 
reiiii is based upon at least a portion of contents 

of said request. 4Q 

18 The system of claim 13. wherein said multiple cor- 
relation is based upon at least one of: 

an address of said requester; and 

a type of service requested by sad request, and 

a quality of service requested by said request. 

19 The system of claim 1 . wherein said multiple corre- 

' latkm is based upon information not explicitly con- ^ 
tained within said request. 

20 The system ot claim 19. wherein said multiple cor- 
relation is based upon at least one of: 

a geographical region ot said receiver; 55 
load information relating to said receiver; 
time information; 
date information; and 



a random factor generated by said name re- 
solver. 

21 A system tor name resolution of at least one request 
* directed to a destination name ot a receiver and is- 
sued from a requester system, the request informa- 
tion relating to caller context, the system including: 
a name resolver connected to the requester 
service and including 

predetermined information correlating a plural- 
ity of service names with said caller context; 
a service selection subsystem configured to 
provide a selection of at least one said service 
s name based upon said caller context; and 

a host name selection subsystem configured to 
return a host name based corresponding to 
said selected sen/ice name. 

>o 22. The system of claim 1, wherein said at least one 
predetermined criterion includes: 

a first criterion based upon inlormation explic- 
itly contained within said request; and 
ss a second criterion based upon information not 

explicitly contained within said request. 

23. The system of claim 22. wherein said second crite- 
rion corresponds to a predetermined policy used by 
30 said name resotver. 

24 The system of claim 23. wherein said first criterion 
corresponds to information relating specifically to 
said requester system. 
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Figure 2A 
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Figure 3 
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Figure 6 
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Figure 7 
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